The increased complexity of modern computer systems often results in an increased quantity of software modules per system and an increased dependency between the software modules on a system. As a result, it has become difficult to avoid conflicts between software modules and ensure that the software modules will perform as expected. The problem of software conflicts is exacerbated when different software modules for a single product are being simultaneously developed at different sites and/or by different companies, and the fact that there may be multiple releases being simultaneously developed that have slightly different packaging requirements. The term software module, as used herein, refers to both computer programs, sections of a program and files used by computer programs.
To avoid software conflict problems, certain standards have been developed which define how software should be packaged (i.e. the form in which software should be released). For example, AT&T has developed application binary interface (ABI) standards suggesting rules for packaging software that runs on the System V, release 4 of UNIX (UNIX SVR4). The ABI standards for UNIX SVR4 may be found in AT&T, SYSTEM V: APPLICATION BINARY INTERFACE, Prentice-Hall, Inc. (1990). The standards consist of a set of rules that dictate how software modules should be packaged and named.
On certain platforms, numerous standard packaging tools have been developed. For example, an install program is available that will install any UNIX SVR4 package that conforms to industry packaging standards. Therefore, conformance with industry packaging standards has the additional benefit that it allows use of standard packaging tools.
In addition to the industry standards, individual companies may have their own software packaging standards. A company's packaging rules may supplement the industry standards or replace them. Further, a company may adopt customized rules that only apply to one release of a product, to all releases of a product, or to a single software package within a product. By conforming to these rules, software developers increase the likelihood that the software modules within their package will interact properly with both other software modules within the package and software modules already existing on the target computer system.
Under certain circumstances, a software developer may determine that a particular product, release, package or file should be exempt from a given rule. For example, a rule may state that executable files should be located in a subdirectory named "bin". A product specific exception to the rule may be appropriate if the developer decides that the executable files for a particular Product X should be located in a subdirectory named "executables". A release specific exception to the rule may be appropriate if the developer decides that the executable files for Product X should be located in "executables" for the beta release of Product X, but located in "bin" for all other releases of Product X. A package specific exception to the rule may be appropriate if the developer decides that the executable files that belong to a Package Y within Product X should be located in "executables", but that all other executables files within Product X should be located in "bin ". A file specific exception to the rule may be appropriate if the developer decides that one particular executable file should be located in "executables", while all others should be located in "bin ".
Under some circumstances, it may be desirable that all files with a particular name should be exempt from a given rule, but that the rule should apply to all other files in the package. For example, a general file-naming rule may prohibit the use of duplicate names. However, it has become customary to include information about changes which were made after the printing of the user's manual in a file named "readme". Thus, various files entitled "readme" may exist in a system, or even in a particular software package. As a result, all files with the name "readme" must be exempt from the duplicate name prohibition rule.
In light of the foregoing, the quantity of packaging rules which apply to any given software release may be significant. For example, there may be multiple layers of rules (industry standard rules, vendor specific rules, release specific rules and package specific rules) as well as multiple layers of exceptions to those rules (vendor specific exceptions, release specific exceptions, package specific exceptions, rule specific exceptions and file specific exceptions).
With such a complex packaging role scheme, it becomes difficult for a vendor to verify the conformity of ("audit") its software packages. The auditing problem becomes even more difficult when software modules for a single package are being simultaneously developed at multiple sites around the world.
In the past, vendors have attempted to enforce packaging rules by designating one or more employees as packaging rule experts. These packaging rule experts must memorize all layers of the rules and determine if and when exceptions to the rules should apply. This approach has a variety of problems, including inefficient human resource management and human error.
Another approach to enforcing packaging rules involves the use of script files. According to this approach, a software programmer develops a script file which, when executed, analyzes a release to determine if the packages within the release conform to packaging rules. The script file contains routines for checking the release for conformity of rules. Unfortunately, the script file must constantly be modified to reflect any variation in the rules or exceptions that apply to any given audit operation.
For example, if a new rule applies to a release, then a routine which checks for conformity to the new rule must be added to the script file. If a release is exempt from a particular rule, then the script file must be modified so that the routine corresponding to the rule is not executed. If a package within a release is exempt from a particular rule, then the routine corresponding to the rule must be modified to ignore errors caused by the particular package. If a file within a release is exempt from a particular rule, then the routine corresponding to the rule must be modified to ignore errors caused by the particular file.
Because script files must be modified to reflect rule/exception variations, it is common for multiple versions of a script file to simultaneously exist, where each version has been customized for a particular audit operation. Thus, the script file approach has the disadvantage that it is difficult to track and control, and virtually impossible to maintain and debug multiple customized script files. Further, the development and modification of script files requires a relatively high degree of programming skill. This could lead to a variety of problems. For example, those who have the responsibility of determining which rules and exceptions apply to a release may not have the requisite programming skills to implement the modifications required to audit the release. Further, attempts by those without the requisite programming skills to implement modifications may jeopardize the integrity of the script file, and therefore the results of the audit operation. If procedural safeguards are adopted to ensure proper development, testing, and version control of script files, the human resources required by such a system would be considerable.
Based on the foregoing, it is desirable to provide a more efficient and flexible system and method for determining whether a software package conforms to industry standard packaging rules. It is also desirable for the system and method to determine whether a software package conforms to company-specific and release-specific packaging rules. It is also desirable that the system and method allow for package-specific and release-specific exceptions to the packaging rules. Further, it is desirable to provide a system in which conformity may be determined automatically, and in which a record of any rule violations is generated automatically. Finally, it is desirable to provide a system that does not require extensive revision before it can be used with different packages and/or different releases with different sets of applicable packaging rules and exceptions.